docs: add end-user tutorials for Krini and CLI - #139

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="docs/researchers/tutorial-cli.md" line_range="109-111" />
<code_context>
+with their `URL`s. If a service isn't listed, use the address that its
+operators gave you.
+
+Before you send a token to a service, check in the [front end of the Cloud
+Registry][elixir-cloud-registry] that it is verified: the CLI doesn't show
+this.
+
+Then add a `TES` and a `WES` section to `~/.ga4gh-cli/config.json` in a text
</code_context>
<issue_to_address>
**Login tokens reach untrusted services**

When a user relies on a verified Registry label for a service they have not independently trusted, including an unsynced or out-of-sync entry, the CLI sends `LS_LOGIN_TOKEN` to the configured service, so an attacker-controlled endpoint can reuse the bearer token to act as the researcher.

Tell users to independently verify the service endpoint and not treat the Registry's verified label as sufficient assurance before sending a token.
</issue_to_address>

### Comment 2
<location path="docs/researchers/tutorial-krini.md" line_range="154" />
<code_context>
+
+    | Field | Value |
+    |---|---|
+    | **Workflow URL** | `https://raw.githubusercontent.com/elixir-cloud-aai/docs/main/docs/researchers/tutorial-files/count-words.cwl` |
+    | **Workflow Type** | `CWL` |
+    | **Workflow Type Version** | `v1.0` |
</code_context>
<issue_to_address>
**Changed workflow executes remotely**

When an attacker alters or compromises the documentation repository's `main` branch before a user follows either tutorial, krini and `ga4gh-cli` submit the mutable `main`-branch CWL URL to WES, which executes its current contents. A malicious replacement therefore runs attacker-controlled workflow code on the selected service instead of the reviewed demo.

Pin the workflow URLs to an immutable revision and update them when the demo changes.

Also at `docs/researchers/tutorial-cli.md:254`.
</issue_to_address>

### Comment 3
<location path="docs/researchers/tutorial-files/count-words.cwl" line_range="10" />
<code_context>
+  DockerRequirement:
+    dockerPull: alpine:3.20
+baseCommand: wc
+stdin: $(inputs.text.path)
+inputs:
+  text:
</code_context>
<issue_to_address>
**Workflow fails on conforming engines**

When a WES service runs a CWL engine that enforces declared requirements, the CWL document uses the JavaScript expression `$(inputs.text.path)` for `stdin` but declares only `DockerRequirement`; an engine that honors CWL requirement declarations refuses to evaluate it, so the workflow fails before `wc` runs and both tutorials cannot produce their advertised result.

Add `InlineJavascriptRequirement: {}` to the document's `requirements`.
</issue_to_address>

### Comment 4
<location path="docs/researchers/tutorial-krini.md" line_range="143-144" />
<code_context>
+3. Point at the info icon next to the service and check that it supports
+   the workflow type `CWL` in the version `v1.0`.
+
+If no service that you can use runs CWL, ask its operator for an example
+workflow in a language that it runs, and use that in the next step.
+
+### 7. Start the workflow
</code_context>
<issue_to_address>
**Alternate workflows cannot be substituted**

When the available WES service runs another workflow language but not CWL v1.0, the next step still requires the supplied CWL workflow and `CWL` v1.0 settings, so the operator-provided workflow in another language is never used and the run is rejected.

Either make a CWL v1.0 service a strict prerequisite and remove the alternative-language advice, or explain how to substitute the operator’s workflow, language, version, and parameters in each tutorial.

Also at `docs/researchers/tutorial-cli.md:243-244`.
</issue_to_address>

### Comment 5
<location path="docs/researchers/tutorial-cli.md" line_range="196" />
<code_context>
+      "command": ["wc", "/data/LICENSE"]
+    }
+  ]
+}' > count-words-task.json
+TASK_ID=$(ga4gh-cli tes create count-words-task.json)
+echo "$TASK_ID"
</code_context>
<issue_to_address>
**Cleanup deletes users’ existing files**

When two tutorial sessions share a working directory, or either output filename already exists there, the fixed-name redirects and `curl -O` overwrite existing files, and cleanup deletes them; with shared sessions, one session can also remove `count-words.json` before the other reaches `wes run`, so the run cannot start.

Use a separate working directory or unique filenames for each session, and ensure cleanup only removes files created by that session.

Also at `docs/researchers/tutorial-cli.md:252`, `docs/researchers/tutorial-cli.md:296`.
</issue_to_address>

### Comment 6
<location path="docs/researchers/tutorial-cli.md" line_range="125" />
<code_context>
+    "base_path": "https://elixir-on.cloud/ga4gh/registry/v1"
+  },
+  "TES": {
+    "base_path": "https://<TES HOST>/ga4gh/tes/v1",
+    "oauth_access_token_env": "LS_LOGIN_TOKEN"
+  },
</code_context>
<issue_to_address>
**Service URLs become malformed**

When a user substitutes a registry `URL` that already includes `https://` and an API path into `<TES HOST>` or `<WES HOST>`, `base_path` then contains a duplicated scheme or API path because the template also adds those components; `ga4gh-cli` requests fail to reach the service, so the tutorial’s service checks and runs fail.

Tell readers to use the registry URL verbatim as `base_path`, adding an API path only when the URL stops before the API root.

Also at `docs/researchers/tutorial-cli.md:129`.
</issue_to_address>